View QG80333M500_6606439.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

the intel? 80333 i/o processor may contain design defects or errors known as errata which may cause the product to deviate from published specifications. current characterized errata are doc- umented in this specification update. order number: 305435-011us intel? 80333 i/o processor specification update april 2006
2 information in this document is provided in connection with intel? products. except as provided in intel?s terms and conditions of sale for such products, intel assumes no liability whatsoever, and intel disclaims any express or implied warranty relating to sale and/or use of intel products, including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright, or other intellectual property right. intel corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property right s that relate to the presented subject matter. the furnishing of documents and other materials and information does not provide any license, express or implied, by estoppel or otherwise, to any such patents, trademarks, copyrights, or other intellectual property rights. intel products are not intended for use in medical, life saving , life sustaining, critical control or safety systems, or in nuc lear facility applications. intel may make changes to specifications and product descriptions at any time, without notice. contact your local intel sales office or your distributor to obtain the latest specifications and before placing your product o rder. copies of documents which have an ordering number and are referenced in this document, or other intel literature may be obtaine d by calling 1-800-548-4725 or by visiting intel's website at http://www.intel.com . anypoint, appchoice, boardwatch, bunnypeople, cableport, celeron, chips, ct media, dialogic, dm3, etherexpress, etox, flashfile , i386, i486, i960, icomp, instantip, intel, intel centrino, intel logo, intel3 86, intel486, intel740, inteldx2, inteldx4, intelsx2, intel cr eate & share, intel gigablade, intel inbusiness, intel inside, intel inside logo, intel netburst, intel netmerge, inte l netstructure, intel play, intel play l ogo, intel singledriver, intel speedstep, intel strataflash, intel teamstation, intel xeon, in tel xscale, iplink, itanium, mcs, mmx, mmx logo, optimizer logo, overdrive, paragon, pc dads, pc parents, pdcharm, pentium, pentium ii xeon, pentium iii xeon, performance at your command, remoteexpress, smartdie, solutions960, sound mark, storageexpress, the computer inside., the journey inside, tokenexpress, voicebrick, vtune, and xircom are trademarks or registered trademarks of intel corporation or its subsidiaries in the united states and other countries. *other names and brands may be claimed as the property of others. copyright ? 2006, intel corporation. all rights reserved.
3 contents contents revision history ......................................................................................... 5 preface ....................................................................................................... 6 summary table of changes ....................................................................... 7 identification information .......................................................................... 13 non-core errata ....................................................................................... 14 core errata............................................................................................... 27 specification changes.............................................................................. 31 specification clarifications........................................................................ 33 documentation changes.......................................................................... 48
4 contents this page intentionally left blank
specification update 5 revision history date version description april 2006 011 added: ? a-1 stepping information to all summary tables and to table 1, ?80333 die details? on page 13 and table 2, ?80333 device id registers? on page 13 ? status change of erratum 35 ? status change of specification change 6 ? status change of specification clarification 52 ? documentation change 4 february 2006 010 added: ? non-core errata 36 ? specification clarification 52 january 2006 009 added: ? non-core errata 35 ? specification change 6 december 2005 008 added: ? revised specification clarification 9 ? specification clarification 49 , 50 , and 51 ? documentation change 3 october 2005 007 added specification clarification 47 and 48 august 2005 006 added: ? non-core errata 33 and 34 ? specification clarification 45 and 46 ? documentation change 2 june 2005 005 added: ? non-core errata 32 ? specification change 5 may 2005 004 added: ? non-core errata 31 ? specification change 3 and 4 april 2005 003 added: ? non-core errata 30 ? specification clarification 44 march 2005 002 added: ? specification change 1 and 2 ? documentation change 1 ? pb-free markings in table 1 february 2005 001 initial release
6 specification update intel? 80333 i/o processor preface preface this document is an update to the specifications contained in the affected documents/related documents table below. this document is a compilation of device and documentation errata, specification clarifications and changes. it is intended for hardware system manufacturers and software developers of applications, operating systems, or tools. information types defined in nomenclature are consolidated into the specification update and are no longer published in other documents. this document may also contain information that was not previously published. affected documents/related documents nomenclature errata are design defects or errors. these may cause the behavior of the intel? 80333 i/o processor 1 (80333) to deviate from published specifications. hardware and software designed to be used with any given stepping must assume that a ll errata documented for that stepping are present on all devices. specification changes are modifications to the current pu blished specifications. these changes will be incorporated in any new release of the specification. specification clarifications describe a specification in greater detail or further highlight a specification?s impact to a complex design situation. these clarifications will be incorporated in any new release of the specification. documentation changes include typos, errors, or omissions from the current published specifications. these will be incorporated in any new release of the specification. note: errata remain in the specification update throughout the product?s life cycle, or until a particular stepping is no longer commercia lly available. under these circumstances, errata removed from the specification update are archived and available upon request. specification changes, specification clarifications and documentation changes are re moved from the specification update when the appropriate changes are made to the appropri ate product specification or user documentation (datasheets, manuals, etc.). title order intel? 80333 i/o processor developer?s manual 305432 intel? 80333 i/o processor datasheet 305433 intel? 80333 i/o processor design guide 305434 intel ? 6700pxh 64-bit pci hub specification update 302706 1. arm architecture compliant.
specification update 7 intel? 80333 i/o processor summary table of changes summary table of changes the following table indicates the errata, specifi cation changes, specification clarifications, or documentation changes which apply to the intel? 80333 i/o processor. intel may fix some of the errata in a future stepping of the component, and account for the other outstanding issues through documentation or specification changes as noted. this table uses the following notations: codes used in summary table stepping x: errata exists in the stepping indicated. specification change or clarification that applies to this stepping. (no mark) or (blank box): this erratum is fixed in listed stepping or specification change does not apply to listed stepping. page (page): page location of it em in this document. status doc: document change or update will be implemented. fixed: this erratum has been previously fixed. no fix: there are no plans to fix this erratum. plan fix: this erratum may be fixed in a future stepping of the product. row change bar to left of table row indicates this erratum is either new or modified from the previous version of the document.
8 specification update intel? 80333 i/o processor summary table of changes non-core errata (sheet 1 of 2) no. stepping page status errata a-0 a-1 1 xx 14 no fix cas latency of three not supported for ddr-ii on-die termination (odt) 2 xx 14 no fix legacy power fail mechanism does not work 3 xx 14 no fix a_req64# and b_req64# initialization pattern timing violation in pci-33 mode 4 xx 15 no fix secondary bus number register (peb sbbnr) provides incorrect bus number 5 xx 15 no fix boundary scan multi-chip module implementation 6 xx 15 no fix pci express* traffic class (tc) bit[2] ignored for malformed packet checks 7 xx 16 no fix auto-refresh command also generates a precharge all command on ddr bus 8 xx 16 no fix coalesced writes to 32-bit memory can cause data corruption 9 xx 17 no fix atu passing rules operation in pci mode 10 xx 17 no fix secondary bus pci rst# pulse prior to the rising edge of pwrgd 11 xx 18 no fix vpd data register bit[19] is not read/write 12 xx 18 no fix pci express* correctable error mask bits 13 xx 18 no fix dma crc result is byte-reversed 14 xx 18 no fix crc corruption on pci-to-local dma transfers 15 xx 19 no fix ioapic end of interrupt (eoi) register is read-write, should be write-only 16 xx 19 no fix unreliable pci express* link operation when l0s active state power management is enabled 17 xx 19 no fix sse bit set for perr# assertion when error reporting is masked 18 xx 19 no fix data parity error detected on pci/x interface fails to propagate bad parity 19 xx 20 no fix atu claims pci commands 8 and 9 when issued as dual address cycle (dac) 20 xx 20 no fix failure to train down in presence of degraded lane 21 xx 21 no fix pci express* and pci-x header logs and first-error pointers do not remain sticky through reset 22 xx 21 no fix incorrect default value for pci express* flow control protocol error severity bit 23 xx 21 no fix power state bits in pci express* power management status and control register mistakenly accept reserved values 24 xx 22 no fix performance across an upstream 1 pci express* link is less than expected 25 xx 22 no fix pci express* esd enhancement requires a change to register setting 26 xx 22 no fix skp ordered set might not be sent within required interval during link recovery when a packet is pending 27 xx 23 no fix serr fatal/non-fatal error message enabled with incorrect error message enabled bit 28 xx 23 no fix configuration write to offset 70h of a- and b-bridge (pm_csr - pci express power management control/status register) using non-continous byte enables does not capture the data value 29 xx 23 no fix the 80333 might become unresponsive when transitioning into the d3 power state 30 xx 24 no fix bus interface unit (biu) claims dac addresses in the range of the memory mapped registers (mmr)
specification update 9 intel? 80333 i/o processor summary table of changes 31 xx 24 no fix tc1(min) of the pci-x clock observed to be marginally less than the requirement specified for the pci-x (mode 1, class1) clock jitter. 32 xx 25 no fix i2c control register reset bit does not function 33 xx 25 no fix msi hot-plug interrupt issue 34 xx 25 no fix under certain conditions, inbound prefetched pci read requests may return wrong data to the requestor 35 x 26 fixed internal clock misalignment can cause processor hang. 36 xx 26 no fix spurious dma0 end-of-transfer interrupt core errata no. steppings page status errata a-0 a-1 1 xx 27 no fix abort is missed when lock command is outstanding 2 xx 27 no fix aborted store that hits the data cac he can mark write-back data as dirty 3 xx 28 no fix performance monitor unit event 0x1 can be incremented erroneously by unrelated events 4 xx 28 no fix in special debug state, back-to-back memory operations?in which the first instruction aborts?can cause a hang 5 xx 29 no fix accesses to the cp15 id register with opcode2 > 001b returns unpredictable values 6 xx 29 no fix disabling and re-enabling the mmu can hang the core or cause it to execute the wrong code 7 xx 30 no fix updating the jtag parallel registers requires an extra tck rising edge 8 xx 30 no fix non-branch instruction in vector table might execute twice after a thumb mode exception non-core errata (sheet 2 of 2) no. stepping page status errata a-0 a-1 specification changes no. steppings page status specification changes a-0 a-1 1 xx 31 doc recommended dll register values 2 xx 31 doc ddr-ii jedec initialization sequence in cludes writes to emrs2 and emrs3 3 xx 32 doc refclk relationship to voltage rails 4 xx 32 doc case temperature (tcase) change 5 xx 32 doc pwrgd and rstin# sequencing 6 x 32 fixed internal clock misalignment.
10 specification update intel? 80333 i/o processor summary table of changes specification clarifications (sheet 1 of 2) no. steppings page status specification clarifications a-0 a-1 1 xx 33 no fix pci express* to pci-x bridge does not support device id messaging (dim) 2 xx 33 no fix 64 mb and 2 gb ddr333 capacities not tested in post-silicon validation 3 xx 33 no fix ddr-ii 400 unbuffered dimms are not supported 4 xx 33 no fix memory map for 2 gbyte of ddr memory 5 xx 33 no fix pci configuration write anomaly when clearing binit[1] 6 xx 33 no fix pwrgd and perst# are the same signals 7 xx 34 no fix back-to-back mcu mmr reads 8 xx 34 no fix reserved idsels on a-segment 9 xx 34 no fix retry disable sequence 10 xx 35 no fix write requirements for the peripheral bus interface 11 xx 35 no fix pci-x status register during pci mode 12 xx 35 no fix m_rst# driven to ddr-ii or ddr-i voltage levels 13 xx 35 no fix biu master abort causes two interrupts on reads 14 xx 36 no fix potential race condition with interrupt controller unit status bits 15 xx 36 no fix reset internal bus (pcsr[5]) usage 16 xx 36 no fix pci express* transaction header log register repeats on offset 124 and 128 17 xx 37 no fix shpc sequence 18 xx 38 no fix bus interface unit follows pci ordering rules 19 xx 39 no fix uart, i2c and gpio memory mapped registers should be addressed with 32-bit accesses 20 xx 39 no fix uart interrupt identification register 21 xx 39 no fix reads on 16-bit pbi bus operate as 32-bit 22 xx 39 no fix 3.3 v to 1.5 v leakage 23 xx 40 no fix accessing extended bridge configuration space from the intel xscale? processor 24 xx 40 no fix recommended b-segment termination when using the 80333 on pci express* adapter cards 25 xx 40 no fix b-segment arbiter might not park on the last master when in pci-x 133 mhz mode 26 xx 40 no fix configuring xintx# signals as pci interrupts 27 xx 41 no fix power plane isolation for battery back-up (bbu) mode 28 xx 41 no fix aau result can be written directly to pci host memory 29 xx 41 no fix smbus connection recommendations for pci express* adapter cards 30 xx 42 no fix pbi lockout condition 31 xx 42 no fix pfreq functionality 32 xx 42 no fix pwrdelay functionality during power sequencing 33 xx 42 no fix hpi# (high priority interrupt) is a maskable interrupt
specification update 11 intel? 80333 i/o processor summary table of changes 34 xx 42 no fix ocd and receive enable calibration de-featured 35 xx 43 no fix pwrdelay needs only a pull-up for battery back-up mode 36 xx 43 no fix pci express* l0s functionality not supported in the 80333 37 xx 43 no fix ddrres2 can be pulled down to reduce current during self-refresh 38 xx 43 no fix ddrslwcres resistor values 39 xx 43 no fix b_pme# routing recommendation when using parallel hot plug 1-slot, no-glue mode 40 xx 44 no fix multi-transaction timer grants fewer clocks in pci mode than expected 41 xx 44 no fix byte enables (be) not included in pci delayed reads can cause data corruption 42 xx 44 no fix interleaving aau descriptors 43 xx 45 no fix rcvdly setting for ddr-i memory 44 xx 45 no fix embedded usage models 45 xx 45 no fix atubar3 functionality 46 xx 45 no fix vref isolation for battery back-up (bbu) mode 47 xx 45 no fix i2c unit enabling 48 xx 46 no fix dma transactions from local memory to a conventional pci target can complete out of order 49 xx 46 no fix sbr1 programming with bank 1 unpopulated 50 xx 46 no fix 32-bit writes to unaligned 64-bit addre sses are promoted to 64-bit aligned writes 51 xx 46 no fix atu retry response through the bridge 52 x 47 fixed case temperature clarification . specification clarifications (sheet 2 of 2) no. steppings page status specification clarifications a-0 a-1
12 specification update intel? 80333 i/o processor summary table of changes documentation changes no. document revision page status documentation changes 1 305433-001 48 doc pci clock timings table missing note 2 305433-002 48 doc wrong voltage values in table 23 3 305432-001 48 doc sbr1 programming when bank 1 is unpopulated 4 305433-003 48 doc pci express clock cycle time minimum
specification update 13 intel? 80333 i/o processor identification information identification information die details table 1. 80333 die details stepping part number qdf (q)/ specification number (sl) processor speed (mhz) notes a-0 nq80333m500 QG80333M500 q010 q108 500 engineering samples pb-free eng samples a-0 nq80333m667 qg80333m667 q011 q109 667 engineering samples pb-free eng samples a-0 nq80333m800 qg80333m800 q012 q110 800 engineering samples pb-free eng samples a-0 nq80333m500 QG80333M500 sl82b sl8cc 500 production pb-free production a-0 nq80333m667 qg80333m667 sl82c sl8cd 667 production pb-free production a-0 nq80333m800 qg80333m800 sl82d sl8ce 800 production pb-free production a-1 nq80333m500 QG80333M500 q611 q614 500 engineering samples pb-free eng samples a-1 nq80333m667 qg80333m667 q612 q615 667 engineering samples pb-free eng samples a-1 nq80333m800 qg80333m800 q613 q616 800 engineering samples pb-free eng samples a-1 nq80333m500 QG80333M500 sl9ba sl9bh 500 production pb-free production a-1 nq80333m667 qg80333m667 sl9bb sl9bj 667 production pb-free production a-1 nq80333m800 qg80333m800 sl9bc sl9bk 800 production pb-free production table 2. 80333 device id registers device and stepping processor device id (cp15, register 0 - opcode_2=0) revision id jtag device id a-0 0x69054210 0x00 0x09268013 a-1 0x69054210 0x00 0x09268013 note: processor core speed can be identified by reading cclkcfg[3:0] (cp14, register 6). 500 mhz = 0x0, 667 mhz = 0x2, 800 mhz = 0x4 note: a-bridge = 0370h, a-ioapic = 0371h, b-bridge = 0372h, b-ioapic = 0373h, atu = 0374h
14 specification update intel? 80333 i/o processor non-core errata non-core errata 1. cas latency of three not supported for ddr-ii on-die termination (odt) problem: for ddr-ii memory with a cas latency (cl) of three, the memory controller unit (mcu) does not provide the proper timing for the on-die termination signals (odt[1:0]). the jedec ddr-ii sdram specification , september 2002 states that odt must be driven one cycle prior to the write command, but the mcu does not meet this timing. implication: cas latency of three is not supported in the 80333; therefore, there is minimal performance impact as compared to cas latency of four. workaround: use cas latency = 4 or do not use the odt feature. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 2. legacy power fail mechanism does not work problem: for previous i/o processor generations, an ex ternal clock was required to maintain the incoming pci clock (p_clk) long enough for the power-fail sequence to be sent to the memory. this is what is referred to as ?legacy power fail.? the internal control circuit that enables the legacy power-fail method is broken. implication: legacy power-fail cannot be used. workaround: for the 80333, a new feature was added which keeps internal clocks running on power fail. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 3. a_req64# and b_req64# initialization pattern timing violation in pci-33 mode problem: the pci local bus specification , revision 2.3 states rst# to req64# hold time is 0 ns minimum and 50 ns maximum (trrh). the 80333 drives the req64# signal for three cycles after rst# deasserts. therefore, in pci-33 mode, this is 90 ns, which violates the 50 ns maximum. all other pci and pci-x modes are within the pci local bus specification , revision 2.3 (that is, pci-66 is 45 ns). implication: no negative impact expected. workaround: there is no overlap between the 80333 assertion of req64# for the initialization sequence, and the first assertion of frame#. as per the pci local bus specification , revision 2.3, trhff defines the minimum time from rst# high to first frame# as sertion as 5 clocks. since the 80333 deasserts req64# at three clocks following rst# high, ther e is no overlap with frame# being asserted as it is not allowed to be asserted any sooner than five clocks. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
specification update 15 intel? 80333 i/o processor non-core errata 4. secondary bus number register (pebsbbnr) provides incorrect bus number problem: the pci express*-to-pci bridge secondary b-segment bus number register (pebsbbnr) does not provide the b-segment bus number. pebsbbnr is to mirror the secondary bus number (scbn) field of the bnum register (bits[15:8] at offset 18h) in the b-segment configuration header space. instead, pebsbbnr provides the subordinate bus number (sbbn) of the bnum register (bits[23:16] at offset 18h) from the a-segment configuration header space. implication: the i/o processor does not su pport transactions from the intel xscale ? processor on a-segment to the b-segment. workaround: to successfully read pci b-segment devices, software can scan the pci b-segment configuration space using configuration reads to determine the bus number. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 5. boundary scan multi-chip module implementation problem: the 80333 is not bsdl-compliant for the sample and bypass instructions specified by the jtag specification 1149.1. it is compliant for most board-level testing. when boards are tested for opens and shorts, the 80333 bsdl can define the boundary scan length as +1 to encompass the bypass register in the intel xscale ? processor (therefore not visible). implication: when doing id, sample, or bypass, the intel xscale ? processor bypass register makes the path from tdi to tdo one flop longer than the jtag specification 1149.1 requires, which can cause canned software to error. note: when neither of these are used by the board vendors during manufacturing testing, there is no issue. workaround: intel can provide two bsdl files which allow op ens and shorts testing, as long as it does not test the id and bypass instructions. one bsdl file covers the intel xscale ? processor unit, and the other bsdl file covers the i/o processor, with th e exception that both in struction sets are reduced from 14 to 7, since they are operating independently. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 6. pci express* traffic class (tc) bit[2] ignored for malformed packet checks problem: pci express* specification , revision 1.0a packet formation rule s state that message (unlock, slot power limit), i/o, cfg tlp must use traffic class 0, such that tc[2:0] of the header field is set to 000. receivers that implement the optional malformed packet check must check for tc usage. the 80333 checks only tc[1:0] and ignores bit[2]. implication: packet formation violations are not detected and flagged as malformed packets. workaround: none status: no fix . see the table , ?summary table of changes? on page 7 . this was originally written with the understanding that malformed packet checks using tc[2:0] were required. it is now understood that the pci express* to pci/pci-x bridge specification 1.0 requires pci express* bridges to ignore tc and forw ard all requests regardless of tc labeling. in order to comply with the pci express* to pci/pci-x bridge specification 1.0 , tc checks are to be removed.
16 specification update intel? 80333 i/o processor non-core errata 7. auto-refresh command also generates a precharge all command on ddr bus problem: when an auto-refresh command is issued to the mcu sdram initialization register (write 0x6 to sdir), the hardware state machine executes a pr echarge all command and then an auto-refresh command. implication: some dimms might fail to initialize. workaround: there is no way to decouple the prechar ge all and auto-refresh commands in the mcu. however, the dcal can issue an auto-refresh co mmand, which can be used instead to issue the auto refresh for initialization. for both ddri and ddrii initialization sequences , there are two back-to-back auto-refresh (arf) commands issued to the dimm (accomplished by writing 0x6 to mcu_sdir 0xffff_e500 twice). this sequence is replaced by writing to the dcal control and status register (dcalsr) 0xffff_f500 to issue an auto -refresh to each chip select; thus, there are four writes to the dcalsr as opposed to the previous two writes to mcu_sdir. the exact address and data values are as follows: address write_data note 0xffff_f500 0x8000_0001 -- arf to cs[0] 0xffff_f500 0x8000_0001 -- arf to cs[0] 0xffff_f500 0x8010_0001 -- arf to cs[1] 0xffff_f500 0x8010_0001 -- arf to cs[1] status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 8. coalesced writes to 32-bit memory can cause data corruption problem: the bus interface unit (biu) can cause data corruption within the memo ry controller unit when either an 8-byte write with a starting address offset of four (that is, dword alignment) or a 12-byte write is done to 32-bit memory (or the 32-bit memory region). implication: this issue can cause data corruption. this is not an issue with 64-bit memory subsystems. workaround: when the use of 32-bit memory or the 32-bit memory region is required, write coalescing must be turned off. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
specification update 17 intel? 80333 i/o processor non-core errata 9. atu passing rules operation in pci mode problem: when the a-segment bus is in pci bus mode, the pci passing rule enforcement logic within the atu allows a read completion to pass write data, until at least four inbound delayed reads, inbound configuration writes, inbound configuration reads, or any combination of these have occurred from the pci bus. implication: this issue causes a deadlock condition in le gacy devices that contain shared read and write data queues, where the device allocates the data buffer for the requested delayed read data and is also being addressed by the outbound atu write data. this atu functionality does not exist in pci-x mode. workaround: use the a-segment bus in pci-x mode. when the a-segment bus is in pci mode, configuration retry is enabled, and the legacy buffer allocating device is present in the system, the atu must not issue writes to that device until the configuration cycles or reads have completed. wh en this situation cannot be achieved by the host, the atu can be momentarily programmed in loo pback mode and issue delayed reads to itself. this workaround is required only when the atu is sending upstream traffic at the same time as the host is configuring it. this should not happen since the atu needs to wait for the driver to be enabled after enumeration completes. this erratum does not occur when configuration re try is deasserted at power-on and the host meets the above configuration cycles. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 10. secondary bus pci rst# pulse prior to the rising edge of pwrgd problem: during system power-on and prior to the 80333 receiving the rising edge of pwrgd, a pulse is observed on the secondary bus pci rst# signals. this functionality is a result of the 3.3v to 1.5v leakage described in specification clarification 22 . other signals that may see a pulse during power- on include the following: all peripheral bus interface (pbi), pci, gpio, uart, jtag and pwrdelay signals. refer to specification clarification 32 for specifics on pwrdelay. signals not included are ddr, pci-express and i2c. implication: pci/pci-x controllers on the secondary bus segments might interpret this pci rst# pulse as a true rising edge and initialize into an undetermined state. pulses on pwe# and pcex# may cause data corruption for memory devices connected to the pbi bus. workaround: a hardware workaround has been identified. use the pwrgd signal that is received by the 80333 to gate the secondary bus pci rst# signals. for example, use pwrgd and a_rst# as inputs to an and gate and connect the output to the secondary device rst# pin. the gate delay must be kept down to ~2 ns, so as to not interfere with the pci initialization pattern. another workaround is to bring up 3.3 v and 1.5 v power rails simultaneously, but continue to maintain the power-sequencing requirements (as specified in the intel? 80333 i/o processor design guide ) for these two power rails. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
18 specification update intel? 80333 i/o processor non-core errata 11. vpd data register bit[19] is not read/write problem: vpd (vital product data) is an extended capability of the atu. bit[19] of the vpd data register (ffff_e1bch) is implemented as rc (read clear) instead of rw (read/write). implication: this is application-dependent, as vpd provides the system with information that uniquely identifies hardware and, potentially, software elements of a system. workaround: when the vpd feature is needed , care must be taken to mask bit[19]. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 12. pci express* correctable error mask bits problem: pci express* correctable error mask (offset 114) requires both pci/pci-x segment a and segment b register bits to be set to take effect. implication: when the mask bit is only set for one segment, the error is still reported to the host bridge. workaround: the 80333 requires mask bits in both a- and b-segments to be set to mask the pci express* correctable errors. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 13. dma crc result is byte-reversed problem: the dma crc result value is byte-reversed. example crc operation with the dma: crc seed: 0x0000 0000 data pattern (16 bytes): 0x1234 5678, 0x1457 9098, 0x1234 5678, 0x1457 9098 expected crc value: 0x6791 25da actual crc value: 0xda25 9167 crc seed: 0x1122 3344 data pattern(16 bytes): 0x1234 5678, 0x1457 9098, 0x1234 5678, 0x1457 9098 expected crc value: 0x1d2c b941 actual crc value: 0x41b9 2c1d implication: data corruption occurs when software does not take care of the byte reversal. workaround: software must byte reverse the crc result after the dma completes. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 14. crc corruption on pci-to-local dma transfers problem: crc corruption can occur when polling dma registers during pci-to-local transfers. crc corruption happens regardless of whether the transfer data is written to memory (dma transfer disable bit dcr.7, is set). both dma channels are affected. implication: crc data corruption occurs. the dma tr ansfer itself is not affected by this erratum. workaround: use local address sour ces only when calculating crc. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
specification update 19 intel? 80333 i/o processor non-core errata 15. ioapic end of interrupt (eoi) register is read-write, should be write-only problem: ioapic end of interrupt register (apic_eoi, offset 40h) should be write-only. the apic specification specifies that this register be implemented as write-only. this register was inadvertently implemen ted as read-write. implication: when implemented as write-only, this regi ster returns ffh when read . since this register is implemented as read-write, the 80333 returns the ?r eal? value of the register contents when read. no negative impact expected. workaround: none status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 16. unreliable pci express* link operation when l0s active state power management is enabled problem: pci express* link operation is unreliable after the l0s state is enabled in the 80333. implication: when l0s is enabled, the system hangs and other system instability occurs. workaround: none status: no fix . not to be fixed. refer to specification clarification 36 ( ?pci express* l0s functionality not supported in the 80333? on page 43 ) and the latest version of the intel ? 6700pxh 64-bit pci hub bios specification update for details on how to disable l0s support. see the table , ?summary table of changes? on page 7 . 17. sse bit set for perr# assertion when error reporting is masked problem: during a downstream memory write to the 80333, the following erroneous behavior is seen when perr# is asserted on the secondary bus: ? signaled system error (sse) in the psts register (d:0, f:0 and 2, offset 06h, bit[14]) is set when serr# enable (see) (d:0, f:0 and 2, offset 04h, bit[8]) and parity error response enable (pere) (d:0, f:0 and 2, offset 04h, bit[6]) are set in the pcicmd register. ? the pere bit in the bctrl register is set (d:0, f:0 and 2, offset 3eh, bit[0]). ? error reporting is disabled in the pcixerrunc_msk register (d:0, f:0 and 2, offset 130h). implication: false indication of an error message escalated as recorded in sse of the psts register being set. this is considered low risk since the escalation of the message is functioning properly. workaround: none status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 18. data parity error detected on pci/x interface fails to propagate bad parity problem: in pci and pci-x mode using 32-bit data transfer s, when a read request is disconnected at an even dword boundary with data parity error, such that the subsequent request for partial data gets retried, the completion for this request is issued over pci express* to the mch (root complex) without the poisoned data ep field set in the pci express* tlp header. implication: corrupted data forwarded without erro r indication when error escalation is not enabled. workaround: uncorrectable error escalation must be en abled in the mch and the 80333 to contain this data parity escape. therefore, a complete workaround fo r this erratum also includes mch/root complex specific bios updates. refer to the latest version of the intel ? 6700pxh 64-bit pci hub bios specification update for details on this workaround.
20 specification update intel? 80333 i/o processor non-core errata note: when error escalation is not properly enabled in the mch/root complex, th ere can be a potential race condition between the completion being returned to the cpu and the error escalation. read completion might complete normally at the cpu followed by error escalation as an interrupt/serr. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 19. atu claims pci commands 8 and 9 when issued as dual address cycle (dac) problem: in pci mode, commands 8 and 9 are reserved. the appropriate pci response to these commands is to master abort. when these commands are issu ed as a dual address cycle (dac), the address translation unit (atu) claims th em, and they are executed as memory read (command 8) and memory write (command 9) on the internal bu s. the atu properly master aborts sac pci commands 8 and 9. this issue does not occur in pci-x mode. implication: no negative impact is expected, since th ese pci commands are ?reserved? and are never normally issued to the atu. workaround: none status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 20. failure to train down in presence of degraded lane problem: during the pci express* training sequence, when a broken endpoint has correct receiver termination on a lane and transmits training sequences on the lane which are invalid, the 80333 fails to link train. implication: the pci express* specification intends that, when some lanes are transmitting invalid data instead of valid training sequences, those lanes must be treated as broken, and the link must fail down to an acceptable width, such as 1. when lane 0 is failing in this manner, the pci express* specification anticipates that the link would fail to train. when a higher-numbered lane is failing in this manner, the pci express* specification requires that the link attempt to train as 1 on lane 0. in either case, the 80333 does not train for the problem scenario. on production material, failures are anticipated to be either a broken transmitter path or a broken receiver path, or a silent transmitter. the 80333 trains properly for these failure modes, since either the receiver termination is missing, or the transmitted signals are not seen at the 80333. in order to see invalid transmitted data on lanes at the 80333, either a logic bug in the other pci express* endpoint is required, or a signal integrity issue so severe as to make operation impossible, such as a broken or intermittent connection. workaround: none. a non-compliant or broken device can exhibit this erratum. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
specification update 21 intel? 80333 i/o processor non-core errata 21. pci express* and pci-x header logs and first-error pointers do not remain sticky through reset problem: the pci express* and pci-x header logs and first-error pointers do not maintain their values after a warm/hot reset. these registers are supposed to be unaffected by a warm/hot reset, but instead, they are reset to default values. the following registers with ?sticky? bits are affected: ? adverr_ctl (offset 118h) ? hdr_log (offset 11ch) ? pci-xerrunc_ptr (offset 138h) ? pci-xhdr_log (offset 13ch) ? pci-xd_log (offset 14ch) ? pci-x_errlogctl (offset 154h) implication: errors detected are logged and escalated properly, but after a warm/hot reset, the header logs and first error pointers reset to their default values. note: error status registers are unaffected, and pr operly maintain their values through reset. workaround: no workaround status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 22. incorrect default value for pci express* flow control protocol error severity bit problem: the pci express* flow control error severity b it (register offset 10c, bit[13]) is programmed to a default value of 0, indicating an uncorrectable flow control error is reported as non-fatal. this is in contradiction with the pci express* specification , revision 1.0a, which requires a default value of 1, indicating an uncorrectable flow control error is reported as fatal. implication: implications for this erratum depend upon the error response strategy implemented in a specific system. workaround: this bit can be reprogrammed to match the specified default value when desired. bios or firmware must set register 10ch bit[13] to 1 for both a- and b-segments. for accessing extended bridge configuration space from the intel xscale ? processor, see specification clarification 23 , ?accessing extended bridge configuration space from the intel xscale? processor? on page 40 . status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 23. power state bits in pci express* power management status and control register mistakenly accept reserved values problem: the power state bits (bits[1:0] of pm_csr at offset 70h), allow a reserved value of 01b or 10b to be written. this is contrary to the specification, which originally stated that when software attempts to write an unsupported reserved state to this field, the data must be discarded and a state change must not occur. implication: when a reserved state is written to this field, there is a mismatch between the actual power state of the part and the state reported in configuration space. in some cases, writing a reserved value to this field can cause the 80333 to transition to the d0 power state, regardless of the previous power state. workaround: do not write a reserved value to this bit field. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
22 specification update intel? 80333 i/o processor non-core errata 24. performance across an upstream 1 pci express* link is less than expected problem: when the 80333 is configured with an upstr eam 1 pci express* link, the realized performance is significantly less than the predicted linear assumption that a x1 link provides 1/4 the performance of a x4 link. this is caused by circumstances where the 80333 must discard a large portion of the data it receives across the upstream link. notably, anytime the 80333 services an incorrect prefetch, or anytime the 80333 services interleaved requ ests from multi-function devices, the 80333 must discard data. implication: devices that rely heavily on prefetching, or multi-function devices that request data in an interleaved fashion, are the most likely to experience degraded performance. workaround: when possible, system designers must reduce the amount of prefetching allowed to devices behind the 80333. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 25. pci express* esd enhancement requires a change to register setting problem: validation has shown pci express* esd enhancement, with changes to undisclosed registers in the 80333. implication: the workaround below increases the margin for the eye and therefor e results in a healthier, improved pci express* link. workaround: bios or firmware must set f0/f2:r260h bit[15] to 1 and clear f0/f2:r270h bit[31] to 0. this workaround is required for both cold and warm reset. status: no fix . not to be fixed. the bios/firmware workaround must be left in place for all 80333 steppings. see the table , ?summary table of changes? on page 7 . 26. skp ordered set might not be sent within required interval during link recovery when a packet is pending problem: during link recovery on the pci express* port, the 80333 might fail to transmit a skp ordered set within the required time interval as defined in the pci express* specification , revision 1.0a when a tlp or dllp was pending when the link entered recovery.idle state. implication: when the receiving device depends upon recei pt of an skp ordered set to progress through link recovery, a time-out occurs, resulting in link down and automatic reinitialization of the pci express* link. a link transitions through recovery only under exceptional operational conditions. following the link recovery time-out and reinitialization, the pci express* link can be expected to resume normal operation unless the original link recovery condition was entered as a result of a hard failure mechanism. workaround: none status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
specification update 23 intel? 80333 i/o processor non-core errata 27. serr fatal/non-fatal error message enabled with incorrect error message enabled bit problem: when the serr# enable (see) bit in the pci command register (offset 0x4) is not set, then in the advanced error reporting scheme when serr is co nfigured as a fatal error, the generation of a serr fatal error message is mistakenly gated by the non-fatal error reporting enabled bit (bit[1]) instead of the fatal error reporting en abled bit (bit[2]) of the device control register (offset 4ch). likewise, when serr is configured as a non-fatal error, the generation of a serr non-fatal error message is gated by the fatal error reporting enabled bit. implication: the serr fatal error message can be genera ted only when non-fatal error messaging is enabled, and vice-versa . workaround: set both fatal and non-fatal error reporting enabled bits, and mask errors individually via uncorrectable pci-x error mask register (offse t 130h) when escalation of these errors is not desired. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 28. configuration write to offset 70h of a- and b-bridge (pm_csr - pci express power management control/status register) using non-continous byte enables does not capture the data value problem: a configuration write to single-byte offset 71h of the a-bridge and b-bridge configuration space does not capture the data value written to it. specifically, performing this configuration write to offset 70h with byte enables of 2h, 6h, or ah in order to write to offset 71h does not work. implication: register offset 70h is the pci express* power management control/status register (pm_csr). the byte at location 71h contains the pme enable bit (bit[8] of 70h) and pme status bit (bit[15] of 70h). the above mechanism does not work to either set or clear the pme enable bit, or to clear the pme status bit. workaround: write to offset 71h by performing a word (byte enable 3h) or a dword (byte enable fh) to offset 70h. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 29. the 80333 might become unresponsive when transitioning into the d3 power state problem: when the 80333 is transitioned to a power state of d3 or lower, the 80333 device might become unresponsive. implication: there have been no obse rved failures on systems with curre ntly available software. operating systems that independently manage the power state of the 80333, outside the scope of system-level power state transitions, might result in the loss of link communications to the mch. workaround: independent device power-state management of the 80333 must be avoided. if the 80333 becomes unresponsive, a fundamental device reset must be asserted to return the system to normal operation. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
24 specification update intel? 80333 i/o processor non-core errata 30. bus interface unit (biu) claims dac addresses in the range of the memory mapped registers (mmr) problem: the biu incorrectly decodes and claims dual address cycle (dac) addresses in the xxxx_xxxx_ffff_e000h to xxxx_xxxx_ffff_ffffh range (e.g. - ?x? represents any bit being set to ?1?). the 32-bit address range of ffff_e000h to ffff_ffffh on the internal bus, represents mmr and reserved space. when a 64-bit address in this range is presented on the internal bus, multiple internal bus units, one of them being the biu, will claim the transaction. note: only the dma can generate a 64-bit address (dac) on the internal bus. implication: using dac addresses in the xxxx_xxxx_ffff_e000h to xxxx_xxxx_ffff_ffffh range on the internal bus will cause an internal bus conflict that may result in the reception of undesired data and setting of error flags. workaround: avoid using the dma with dac addresses in the xxxx_xxxx_ffff_e000h to xxxx_xxxx_ffff_ffffh range. this can be done by utilizing one of the two 64mb atu outbound memory windows (8000 0000h or 8400 0000h) and its corresponding outbound translation registers (omwtvr0/oumwtr0 or omwtvr1/oumwtr1) in order to present a 32 bit address on the internal bus and generate a 64 bit address on the pci bus. the upper translate value register should be programmed with the upper 32 bits of the desired pci address. the lower translate value register woul d then be configured to or in the appropriate value such that the desired lower 32 bits appear on the pci bus after translation. refer to section 3.2.2 ?outbound transactions ? single address cy cle (sac) internal bus transactions? in the intel? 80333 i/o processor developer?s manual for more information on how the windowing and translation scheme works. it is possible to now generate the 32 bit internal bus transaction either using the core or the dma. both options are viable and one may be preferable over the other depending on the application. note: use of the dma to generate the transaction would require not only the modification of the descriptors in question and setting of the memory-memory transfer enable bit (dcrx) for those descriptors, but care must also be taken not to allow any individual transfer to overrun the size of the outbound window (64mb). status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 31. tc1(min) of the pci-x clock observed to be marginally less than the requirement specified for the pci-x (mode 1, class1) clock jitter. problem: the 80333 generates the pci-x clock with a nominal frequency of 133 mhz (tc1 of 7.5 ns). after considering the clock jitter, the minimum clock period (tc1(min)) observed at the pin may be less than 7.5 ns. the pci-x class 1 clock jitter specification for mode 1 requires the tcyc-min to be 7.5 ns with jitter consideration. the same applies for the pci-x clock generated @ 66 mhz. implication: no negative impact is expected, when compliant with the routing guidelines. workaround: there is no workaround to adjust the mi nimum clock period (tc1(min)) of the pci-x clocks. however, the routing guidelines for the pci-x clock signal take into consideration the effect of the jitter on the minimum clock period (tc1(min)). conforming to the routing guidelines in the 80333 design guide will offset the effect of the marginally reduced minimum clock period (tc1(min)) towards the setup and hold times. therefore, for sy stem boards that are co mpliant with the routing guidelines, the risk of violating the setup and hold time requirements and any resulting functional impact, is low. please refer to the 80333 i/o processor design guide (305434) for further information on the pci-x clock routing guidelines. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
specification update 25 intel? 80333 i/o processor non-core errata 32. i2c control register reset bit does not function problem: the i2c control register (icr0 and icr1) bit 14 is supposed to be used for resetting the i2c unit, but writing a '1' to this bit does not reset the i2c unit. writing a '1' to bit 14 has no effect. implication: the i2c unit cannot be reset by using icrx.14. workaround: depends on what needs to be accomplished. asserting p_rst# or setting bcr.6 will reset the i2c unit but will also reset the entire chip or the secondary bus/atu. for an i2c bus lock condition, it may be cleared by software doing a toggle of the gpod[11:10] to toggle scl[1:0]. if sda[1:0] need to be toggled, then an external device or un used gpio will need to be used to control this sequence. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 33. msi hot-plug interrupt issue problem: an msi generated by the standard hot-plug controller may get corrupted in the presence of another acpi hot-plug driver. the acpi driver performs configuration reads of dwsel/dword register in order to determine the hot-plug capability of all the acpi devices. if the msi is generated by the standard hot-plug controller (shpc) in this time period, there is a possibility of the msi getting corrupted. as a result the msi may not get issued upstream to the mch. the above is a result of interaction of separate events that are unpredictable. implication: with the above condition described, the hot-plug device may not get recognized by the os. currently this issue is susceptible to only msi aware systems. workaround: disable 80333 shpc msi. by default msi_mc (offset 5eh, function 2 only) bit 0 msi enable is clear. bios/fw must keep this default value. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 . 34. under certain conditions, inbound prefetched pci read requests may return wrong data to the requestor problem: with some prefetch policy settings, the 80333 may over-aggressively prefetch data for pci reads and subsequently return the wrong data to the re questor. this problem only exists when there is more than one active agent on the pci bus. this pr oblem exists for all supported frequencies. this problem exists on both 80333 pci segments. this problem does not affect pci-x operation at any supported frequency. implication: inbound read requests that are enabled for prefetching may return invalid data when multiple agents exist on the same pci bus. no error is reported by the 80333. workaround: bios or firmware must set d0:f0/f2 offset 184h (dword) bit [2] to 1. the workaround corrects the problem at all supported frequencies and all prefetch policy settings. status: no fix not to be fixed. the bios/firmware work around must be left in place for all 80333 steppings. see the table , ?summary table of changes? on page 7 .
26 specification update intel? 80333 i/o processor non-core errata 35. internal clock misalignment can cause processor hang problem: after a reset, the 80333 can hang during initial accesses to sdram, due to a possible clock misalignment, aggravated by a race conditi on in the clock divider clear circuit. implication: a failure will manifest itself as a hang of the i/o processor after reset, during initial accesses to sdram. subsequent warm or cold resets may clear the condition and allow the 80333 to continue operation. workaround: in most cases, doing a cold or warm reset will clear this condition. increasing the 1.5v power supply will reduce the probability of a processor hang. intel is screening parts to eliminate the probability of occurrence (refer to specification change #6, ?internal clock misalignment? on page 32 ). status: fixed. this issue was fixed in the a-1 stepping of the product (this is also related to section 6, ?internal clock misalignment? on page 32 ). see the table , ?summary table of changes? on page 7 . 36. spurious dma0 end-of-transfer interrupt problem: when the interrupt controller goes from having no interrupts asserted to one or more asserted, there is a 1-clock cycle window in which the iintvec (irq interrupt vector register; ffff_e7c8h or cp6, register 14) or fintvec (fiq interrupt vector register; ffff_e7cch or cp6, register 15) may report the value of the intbase register (interrupt base register; ffff_e7c0h or cp6, register 12), which is the vector address for interrupt 0, dma0 end-of-transfer. this condition can occur even if the dma0 eot interrupt is masked, intctl0.0 = 0. implication: no negative impact expected. if the rou tine that reads the iintvec/fintvec qualifies the return value against iintsrc0.0/fintsrc0.0, it will either see there is nothing to do or it will validly call the dma0 end-of-transfer handler. workaround: if iintvec/fintvec equals intbase, then re-read the iintvec/fintvec register. status: no fix . not to be fixed. see the table , ?summary table of changes? on page 7 .
specification update 27 intel? 80333 i/o processor core errata core errata 1. abort is missed when lock command is outstanding problem: a bus abort occurs on a code fetch while an instruction tlb or i-cache lock mcr, move to coprocessor from arm register, command is outstanding. the core fails to abort, instead executing the instruction returned on the aborting transaction. parity errors are not affected. the bus abort can be due to either an abort pin assertion or a multi-bit ecc error. workaround: branch flush after every i-tlb or i-cache lock. for example, the following instruction does this: sub pc, pc #4;flush the pipe. status: no fix . see the table , ?summary table of changes? on page 7 . 2. aborted store that hits the data cache can mark write-back data as dirty problem: when there is an aborted store that hits clean data in the data cache (data in an aligned four-word range that has not been modified from the core sin ce it was last loaded in from memory or cleaned), the data in the array is not modified (the store is blocked), but the dirty bit is set. when the line is then aged out of the data cache or explicitly cleaned, the data in that four-word range is evicted to external memory, even though it has never been changed. in normal operation this is nothing more than an extra store on the bus that writes the same data to memory that is already there. here is the boundary condition where this might be visible: 1. a cache line is loaded in to the cache at address a. 2. another master externally modifies address a. 3. a core store instruction attempts to modi fy a, hits the cache, aborts because of mmu permissions, and is backed out of the cache. that line normally is not marked dirty, but because of this erratum, it is marked as dirty. 4. the cache line at a then ages out or is explicitly cleaned. the original data from location a is evicted to external memory, overwriting the data written by the external master. this happens only when software is allowing an external mast er to modify memory that is, write-back or write-allocate in the core page tables, and dependin g on the fact that the data is not ?dirty? in the cache, to preclude the cached version from overwriting the external memory version. when there are any semaphores or any other handshaking to prevent collisions on shared memory, this is not a problem. workaround: for this shared memory region, mark it as write-through memory in the core page table. this prevents the data from ever being written out as dirty. status: no fix . see the table , ?summary table of changes? on page 7 .
28 specification update intel? 80333 i/o processor core errata 3. performance monitor unit event 0x1 can be incremented erroneously by unrelated events event 0x1 in the performance monitor unit (pmu) can be used to count cycles in which the instruction cache cannot deliver an instruction. the only cycles counted are supposed to be those due to an instruction cache miss or an instructi on tlb miss. the following unrelated events in the core, also causes the corresponding count to incr ement when event number 0x1 is being monitored: ? any architectural event (for example, irq, data abort) ? msr instructions which alter the cpsr control bits ? some branch instructions, including indirect branches and those mispredicted by the btb ? cp15 mcr instructions to registers 7, 8, 9, or 10, which involve the instruction cache or the instruction tlb. each of the preceding items can cause the perfor mance-monitoring count to increment several times. the resulting performance monitoring count can be higher than expected when the preceding items occur, but has not been observed to be lower than expected. workaround: there is no way to obtain the correct number of cycles stalled due to instruction cache misses and instruction tlb misses. extra counts, due to bran ch instructions mispredicted by the btb, might be one component of the unwanted count that can be filtered out. the number of mispredicted branches also can be monitored using performance-monitoring event 0x6 during the same time period as event 0x1. the mispredicted branch number can then be subtracted from the instruction cache stall number generated by the performance monitor to get a value closer to the correct one. this workaroun d addresses only counts contributed by branches that the btb is able to predict. all the items in the preceding bulleted list still affect the count. depending on the nature of the code being monitored, this workaround might have limited value. status: no fix . see the table , ?summary table of changes? on page 7 . 4. in special debug state, back-to-back memory operations?in which the first instruction aborts?can cause a hang problem: when back-to-back memory operations occur in the special debug state (sds, used by ice and debug vendors), and the first memory operation gets a precise data abort, the first memory operation is correctly cancelled and no abort occurs. depending on the timing, however, the second memory operation might not work correctly. th e data cache might internally cancel the second operation, but the register file may have scoreboa rded registers for that second memory operation. the effect is that the core might hang (due to a permanently scoreboarded register) or that a store operation might be incorrectly cancelled. workaround: in special debug state, any memory operation that can cause a precise da ta abort must be followed by a write-buffer drain operation. this precludes further memory operations from being in the pipe when the abort occurs. load multiple/store multiple that might cause precise data aborts must not be used. status: no fix . see the table , ?summary table of changes? on page 7 .
specification update 29 intel? 80333 i/o processor core errata 5. accesses to the cp15 id register with opcode2 > 001b returns unpredictable values problem: the arm architecture reference manual (arm ddi 0100e) states the following in chapter b-2, section 2.3: when an value corresponding to an unimplemented or reserved id register is encountered, the system control processor retu rns the value of the main id register. id registers other than the main id register are defined so that when implemented, their value cannot be equal to that of the main id register . software can therefore determine whether they exist by reading both the main id register and the desired register and comparing their values. when the two values are not equal, the desired register exists. the intel xscale ? processor does not implement any cp15 id code registers other than the main id register (opcode2 = 000b) and the cache type register (opcode2 = 001b). when any of the unimplemented registers are accessed by software (f or example, mrc p15, 0, r3, c15, c15, 2), the value of the main id register is to be return ed. instead, an unpredictable value is returned. workaround: none status: no fix . see the table , ?summary table of changes? on page 7 . 6. disabling and re-enabling the mmu can hang the core or cause it to execute the wrong code problem: when the mmu is disabled via the cp15 control register (cp15, cr1, opcode_2 = 0, bit[0]) after being enabled, certain timing cases can cause the processor to hang. in addition to this, re-enabling the mmu after disabling it can cause the proces sor to fetch and execute code from the wrong physical address. to avoid these issues, the code sequence below must be used whenever disabling the mmu or re-enabling it afterwards. workaround: the following code sequence can be used to disable and/or re-enable the mmu safely. the alignment of the mcr instruction that disables or re-enables the mmu must be controlled carefully, so that it resides in the first wo rd of an instruction cache line. @ the following code sequence takes r0 as a parameter. the value of r0 will be @ written to the cp15 control register to either enable or disable the mmu. mcr p15, 0, r0, c10, c4, 1 @ unlock i-tlb mcr p15, 0, r0, c8, c5, 0 @ invalidate i-tlb mrc p15, 0, r0, c2, c0, 0 @ cpwait mov r0, r0 sub pc, pc, #4 b 1f @ branch to aligned code .align 5 1: mcr p15, 0, r0, c1, c0, 0 @ enable/disable mmu, caches mrc p15, 0, r0, c2, c0, 0 @ cpwait mov r0, r0 sub pc, pc, #4 status: no fix . see the table , ?summary table of changes? on page 7 .
30 specification update intel? 80333 i/o processor core errata 7. updating the jtag parallel registers requires an extra tck rising edge problem: the ieee 1149.1 specification states that th e effects of updating all parallel jtag registers are expected to be seen on the falling edge of tck in the update-dr state. the intel xscale ? processor parallel jtag registers incorrectly requir e an extra tck rising edge to make the update visible. therefore, operations like hold-reset, jtag break, and vector traps require either an extra tck cycle by going to run-test-idle or by cyc ling through the state m achine again in order to trigger the expected hardware behavior. workaround: when the jtag interface is polled continuous ly, this erratum has no effect. when not, an extra tck cycle can be caused by going to run-test-idle after writing a parallel jtag register. status: no fix . see the table , ?summary table of changes? on page 7 . 8. non-branch instruction in vector table might execute twice after a thumb mode exception problem: when an exception occurs in thumb mode and a non-branch instruction is executed at the corresponding exception vector, that instruction might execute twice. typically instructions located at exception vectors must be branch instructions which go to the appropriate handler, but the arm architecture allows the fiq handler to be placed directly at the fiq vector (0x0000001c/0xffff001c) without requiring a branch. because of this bug, the first instruction of such an fiq handler might be executed twice when it is not a branch instruction. workaround: when a ?nop? is placed at the beginning of the fiq handler, the ?nop? executes twice and no incorrect behavior results. when a branch instructio n is placed at the beginning of the handler, it is not executed twice. status: no fix . see the table , ?summary table of changes? on page 7 .
specification update 31 intel? 80333 i/o processor specification changes specification changes 1. recommended dll register values issue: using the default dll values in combination with low duty cycle dimms may result in low hold time margins on read transactions. the default values for the dll master and slav e registers do not center the internal dqs with respect to the eye of the incoming data. using the default values may result in a reduced hold time due to dqs being late in the data eye, which could lead to ecc errors. errors have only been observed when using dimms that have a low dqs duty cycle. note: all of the intel validation up to this point has been with the default, worst case dll values and all dimms used in validation have passed. firmware should be updated and tested with these new dll values, in order to add margin to the hold timing during memory reads. ddr-ii 400 settings slvlmix0 - address ffff_f554h; recommended value - 3333_3333h slvlmix1 - address ffff_f558h; recommended value - 0000_0003h slvhmix0 - address ffff_f55ch; recommended value - 3333_3333h slvhmix1 - address ffff_f560h; recommended value - 0000_0003h slvlen - address ffff_f564h; recommended value - 0000_0003h mastmix - address ffff_f568h; recommended value - 0000_000ah mastlen - address ffff_f56ch; recommended value - 0000_0002h ddr-i 333 settings slvlmix0 - address ffff_f554h; recommended value - 6666_6666h slvlmix1 - address ffff_f558h; recommended value - 0000_0006h slvhmix0 - address ffff_f55ch; recommended value - 6666_6666h slvhmix1 - address ffff_f560h; recommended value - 0000_0006h slvlen - address ffff_f564h; recommended value - 0000_0003h mastmix - address ffff_f568h; recommended value - 0000_0000h mastlen - address ffff_f56ch; recommended value - 0000_0002h 2. ddr-ii jedec initialization sequence includes writes to emrs2 and emrs3 issue: the jedec ddr-ii specification includes a write to emrs2 and emrs3 (extended mode register set) during the initialization sequence. step 5 is ?issue emrs2 command? and step 6 is ?issue emrs3 command?. in order to be jedec compliant, these steps should be added to the memory controller initialization sequence. note: before implementing, check with your dimm/memory manufacturer to determine if these steps are necessary. software should always follow the initialization sequence provided by the dimm/memory manufacturer guidelines. the following pseudo code shows the emrs initia lization steps that are required to be compliant with the jedec ddr-ii initialization sequence. // step 5 and 6 - emrs(2) and emrs(3) programming
32 specification update intel? 80333 i/o processor specification changes if memorytype is ddr-ii write 0x2 to dcaladdr (setting ba[1:0] for emrs(2)) write 0x81000003 to dcalcsr (issue emrs command to cs0) wait for dcalcsr[31] to report ?operation completed? write 0x81100003 to dcalcsr (issue emrs command to cs1) wait for dcalcsr[31] to report ?operation completed? write 0x3 to dcaladdr (setting ba[1:0] for emrs(3)) write 0x81000003 to dcalcsr (issue emrs command to cs0) wait for dcalcsr[31] to report ?operation completed? write 0x81100003 to dcalcsr (issue emrs command to cs1) wait for dcalcsr[31] to report ?operation completed? endif 3. refclk relationship to voltage rails issue: the current 80333 design guide (305434) states the following in section 10.1: "also, all 80333 voltage rails must be stable and within their operating ranges before the pci express differential clocks refclk+ and refclk- begin running. this is a requirement for all devices with pci express interfaces." when the 80333 is on an add-in card, only 3.3v and 12v are provided to the slot, therefore, a local regulator is required for 1.5v and 2.5v generation. due to the delay by the local regulators, refclk may already be provided before the power rails are stable. if this is the case, no device overstress will occur, provided that the refclk input current does not exceed 900ma and the input voltage does not exceed the pci express specification of 1.15v. refclk buffers on many intel platforms show an input current of 15.6ma, well under the 900ma limit. the requirement for "all 80333 voltage rails to be stable before the pci express differential clocks refclk+ and refclk- begin running" is no longer a requirement. 4. case temperature (tcase) change issue: to be consistent with the production test en vironment, the case temperature (tcase) for the 80333 i/o processor has been changed from 105 o c to 95 o c. 5. pwrgd and rstin# sequencing issue: strapping rstin# high (as stated in the 80333 design guide v001, table 3), bringing rstin# up prior to pwrgd rising edge or tying pwrgd and rstin# together, could result in platform failures. the correct sequencing between pwrgd and rstin# , is for the rising edge of rstin# to follow the rising edge of pwrgd by at least 1ms. 6. internal clock misalignment issue: due to non-core erratum 35, internal clock misalignment can cause processor hang, on page 26 , intel is screening parts to eliminate the probability of occurrence. until this is fixed in a future stepping, a screen has been implemented which will screen out parts exhibiting this issue with a vcc15 greater than 1.46v. with the screen at 1.46v, the on-board 1.5v power rail should not be allowed to go below 1.46v, as this would increase the risk of failure. the 1.5v ra il minimum is currently specified in the datasheet as 1.425v, therefore for screened parts, the minimum is changed to 1.46v. status: fixed. this issue was fixed in the a-1 stepping of the product.
specification update 33 intel? 80333 i/o processor specification clarifications specification clarifications 1. pci express* to pci-x bridge does not support device id messaging (dim) issue: the pci express* to pci-x bridge does not forward dim transactions. this is an optional feature in the pci express* to pci/pci-x bridge specification, rev. 1.0 . status: no fix . see the table , ?summary table of changes? on page 7 . 2. 64 mb and 2 gb ddr333 capacities not tested in post-silicon validation issue: intel is not able to test 64 mb and 2 gb ddr333 dimms due to availability. intel cannot guarantee proper functionality since validation cannot be completed. status: no fix . see the table , ?summary table of changes? on page 7 . 3. ddr-ii 400 unbuffered dimms are not supported issue: the 80333 supports ddr333 buffered (registered) and unbuffered dimms, but supports only ddr-ii 400 buffered (registered) dimms. ddr-ii 400 unbuffered dimms are not supported. status: no fix . see the table , ?summary table of changes? on page 7 . 4. memory map for 2 gbyte of ddr memory issue: the 80333 can support up to 2 gbytes of ddr sdram, but it cannot cross a 2 gb boundary. therefore it must be mapped to either 0x00000000?0x7fffffff or 0x80000000?0xffffffff. either range conflicts with one or more of the statically assigned regions. the recommendation is to disable the direct outbound atu window, in order to use the larger 2 gb memory, by clearing atucr[8] (default setting is 0?disabled). status: no fix . see the table , ?summary table of changes? on page 7 . 5. pci configuration write anomaly when clearing binit[1] issue: there is an anomaly when the atu does a c onfiguration write to binit[1] of the a-segment configuration header. when clearing bit[1] by writing 00000009h to the binit configuration register (offset fch), the pci bridge retries th e write the first time. the pci specification states that no data is to be transferred on retries. the configuration register is updated to 00000009h; therefore, data did get transferred on the retry. the pci bridge ignores the second write, giving a master abort. binit[1] has a bit attr ibute of read and write once (rwos). the worst-case implication is that a master abort error occurs when turning off inbound configuration accesses (binit[1]?a-segment). this anomaly is not seen when the a-segment is running in pci-x mode, but only when in pci mode. status: no fix . see the table , ?summary table of changes? on page 7 . 6. pwrgd and perst# are the same signals issue: the 80333 uses pwrgd to identify the primary reset signal as described in the pci express card electromechanical specification , revision 1.0. this is the same signal as perst#, which is described in the pci express card electromechanical specification , revision 1.0a. status: no fix . see the table , ?summary table of changes? on page 7 .
34 specification update intel? 80333 i/o processor specification clarifications 7. back-to-back mcu mmr reads issue: the memory controller unit (mcu) returns the wrong memory-mapped register (mmr) read data, when two mmr read transactions are enqueued into the transaction queues at the same time. this cannot happen from the biu port as mapping the mmrs to this space is not allowed. the only way this can occur is for two internal bus devices to request info from the mcu mmrs at the same time (with different addresses). fo r example, the biu (via the intel xscale ? processor) and the atu (via the host), which is a very unlikely usage model. status: no fix . see the table , ?summary table of changes? on page 7 . 8. reserved idsels on a-segment issue: the intel? 80333 i/o processor developer?s manual added table 9, which shows ad24?ad27 as ?reserved? idsels for the a-segment. these are reserved so that the intel xscale ? processor can access the extended configuration space of the brid ge by using type-0 configuration cycles. the a-side bridge can also be accessed by type-1 configuration cycles, but the primary bus number of the bridge must be tracked. on power-up, before the configuration retry bit is cleared, it is zero. when this technique is used, the ad24 and ad25 can be used for public or private devices based on binit[4], and ad26 and ad27 can be used for public devices. status: no fix . see the table , ?summary table of changes? on page 7 . 9. retry disable sequence issue: the 80333 has three integrated units (a-bridge , b-bridge, and atu) that include retry bits, and these must be disabled in a specific sequence. when the retry bit is set, the pci interface responds to all type-0 configuration cycles with a retry transaction. when the retry bit is cleared, type-0 transactions are completed normally. the default condition of the retry bit is determined by the retry reset strap muxed on ad[6]. note: since a pcix reset independent of a pcie reset will result in a reset of the intel xscale ? processor without resetting the bridge registers, the bridge retry release sequence must not be executed if the bridge retry bit is not set. code can check the a segment binit register (bit 3) to determine if the bridge retry bits need to be cleared or not. proper retry disable sequence as initiated by the intel xscale ? processor: 1. set the bus master enable bit for the atu in atucmd[2] (offset 04h) and enable the outbound atu in the atucr. 2. read a segment binit to determine if bridge is currently retrying type 0 config cycles. 3. if the bridge is retrying cycles (read a-brid ge binit register and check if bit 3 is set): a. set the bus master enable bit for the a-bridge in pcicmd[2] (offset 04h). b. read the primary bus number from the a-bridge for use in creating the type 1 transaction to the b side. c. enable the bridge (a side at a minimum, b side if application requires) to pass config retry cycles upstream by setting bit 15 in the pci express device control register register at offset 0x4c. d. implement any errata workarounds that require bridge configuration cycle setup. e. clear the b-bridge retry bit in binit[3] (offset fch using a type 1 transaction as defined in the pci specification).
specification update 35 intel? 80333 i/o processor specification clarifications f. restore the a-bridge command register and clear the a-bridge retry bit in binit[3] (offset fch). 4. clear (restore) the bus master enable bi t for the atu in atucmd[2] (offset 04h). 5. clear the atu retry bit in pcsr[2] (offset 84h). note: access to the bridge configuration header space is done by using a configuration cycle, which is generated by the atu occar and occdr registers. status: no fix . see the table , ?summary table of changes? on page 7 . 10. write requirements for the peripheral bus interface issue: pbi write requirements are as follows: ? the flash or memory must be set up to accept writes. ? each write must be checked to make sure it ha s completed, before the next write can start. ? it is now allowed to burst writes to the pbi. the data presented must not be larger than the pbi width. every pbi device must be mapped in the mmu the same way. making the device address space cacheable can result in buffered/coalesced writes, which are burst to the pbi. xcb = 000 and xcb = 101 are the only cache policies that can be used for pbi. all other cache policies result in multi-byte transactions. status: no fix . see the table , ?summary table of changes? on page 7 . 11. pci-x status register during pci mode issue: the pci-x status register (px_sr, offset e4 h-e5h) in the atu has meaning only in pci-x mode. the device number and bus number fields are always updated when a configuration write is detected. the atu always grabs ad[15:11] for conf iguration writes, whether it is in pci or pci-x mode. when a pci configuration transaction occurs , the device number bits[7:3] are updated to a value of 00000b from the default value of 11111b. the bus number bits[15:8] are grabbed only during the attribute phase (which does not exist for pci). status: no fix . see the table , ?summary table of changes? on page 7 . 12. m_rst# driven to ddr-ii or ddr-i voltage levels issue: the de-asserted voltage level on m_rst# with ddr-ii is 1.8 v and with ddr-i is 2.5 v. when m_rst# is needed for other devices (for example, flash), make sure these voltage levels are appropriate for the target device. status: no fix . see the table , ?summary table of changes? on page 7 . 13. biu master abort causes two interrupts on reads issue: the bus interface unit (biu) will generate an interrupt when the biu gets master aborted on an internal bus write. the functionality is different be tween a read and write case. for a write, the biu master abort asserts iintsrc[29] (when enabled) an d does not assert an error to the core. for a read, the biu master abort asserts both iintsrc[29] (when enabled) and an error to the core. therefore, on a read case two interrupts is gene rated. when the interrupt source is masked, then only the master abort on reads is detected , and this is from the direct core error. status: no fix . see the table , ?summary table of changes? on page 7 .
36 specification update intel? 80333 i/o processor specification clarifications 14. potential race condition with interrupt controller unit status bits issue: there is a slight lag in the time it takes between clearing a status bit inside the unit and the corresponding bit in the interrupt controller unit status register getting cleared. this has the potential of generating a false interrupt, meaning that the intel xscale ? processor is interrupted, but the handler is not able to find any source reported in the icu registers. this condition can be avoided by adding a read from any icu register, af ter the bit is cleared in the local unit before returning from the interrupt handler. the data from this read can be ignored, but the read itself creates enough latency to allow the updated status to propagate to the icu. status: no fix . see the table , ?summary table of changes? on page 7 . 15. reset internal bus (pcsr[5]) usage issue: pci bus data corruption can occur when the rese t internal bus bit is not used correctly. pcsr[5] can be used to reset the internal bus. this resets all memory-mapped registers and the atu configuration header space. this bit is read/write-capable from bo th the internal bus and pci bus. for both pci and pci-x modes, make sure the following steps occur when setting pcsr[5]: 1. clear bus master (atucmd[2]) enable and memory enable (atucmd[1]). 2. wait for both the outbound (pcsr[15]) and inbound (pcsr[14]) read transaction queue busy bits to clear. 3. make sure no pci configuration read/write cycles targeting the atu are in progress, except the reset configuration write, when applicable. 4. set the reset internal bus bit. 5. wait for 40 pci clocks. status: no fix . see the table , ?summary table of changes? on page 7 . 16. pci express* transaction header log register repeats on offset 124 and 128 issue: the lower 32 bits of the address of the sing le address cycle (sac) are mirrored onto the upper 32 bits in the log register giving the appearan ce that a dual address cycle (dac, 64-bit address transaction) occurred instead of a sac (singl e address cycle, 32-bit address transaction). the lower 32 bits of the address are on the third dword and the upper are on the fourth dword. the fourth dword is ?reserved? for a sac transac tion. so, instead of the fourth dword defaulting to 0 as expected, it actually mirrors the third dword. for example: for a 32-bit tlp (memory write with poisoned bit set) downstream transaction to the 80333, the header log (offset 11c?12b) could look like this: offset: 0x11c, before: 0x00000000, after: 0x40004005 offset: 0x120, before: 0x00000000, after: 0x000000ff offset: 0x124, before: 0x00000000, after: 0x06000000 offset: 0x128, before: 0x00000000, after: 0x06000000 status: no fix . see the table , ?summary table of changes? on page 7 .
specification update 37 intel? 80333 i/o processor specification clarifications 17. shpc sequence issue: when using parallel 1-slot, no-glue hot-plug mode, the frequency does not update correctly with a single reset; therefore, two b-segment resets are required. the first reset is needed to correctly latch in the b_pcixcap and b_m66en, and the s econd reset is needed to execute the change frequency command. this sequence must be followed: 1. pwrgd 0 -> 1 (hw) 2. b_rst# 0 -> 1 (hw), at this time hprst# is 0 3. enable slot power (sw normal sequence) 4. issue hot-plug change frequency with code 40 (pci = 33m). 5. hprst# 0 -> 1 (sw slot enable) 6. hprst# = 1 (change frequency) [note: this is a software step. bus reset happens automatically due to the change frequency.] ?operating? 7. hprst# 1 -> 0 (sw slot disable) ?off/removal? ?new card inserted? 8. go to step 2 status: no fix . see the table , ?summary table of changes? on page 7 .
38 specification update intel? 80333 i/o processor specification clarifications 18. bus interface unit follows pci ordering rules issue: the core bus interface unit orders transactions based on pci rules. this allows outgoing writes to pass incoming reads. for most devices on the inte rnal bus, this does not cause problems since the devices function asynchronously with respect to each other. for transactions between the intel xscale ? processor and memory via the internal bu s, this can result in unexpected data. for example: 0: ldr r0, =0x40000 1: ldr r1, =0xaaaaaaaa 2: ldr r2, =0x55555555 3: str r1, [r0] 4: ? 5: ldr r3, [r0] 6: str r2, [r0] this code can potentially load the register r3 with the value 0x55555555, since the store in line 6 might pass the load in line 5. this happens only with uncached transactions on the internal bus. the mcu core port enforces strict ordering an d does not exhibit this behavior. when the mcu core port is used, this issue does not occur. when caching is enabled, the initial read initiates a cache-line fill. the subsequent write is pended in the intel xscale ? processor until the line fill and the ldr instruction complete. in this case, this issue does not occur. when caching is disabled, and the caching policy is stall-until-complete (x = 0, c = 0, b = 0), this issue does not occur. for other mmu settings with caching disabled, the issue can occur. specifically regions with data cache and write buffer policies of bufferable (x = 0, c = 0, b = 1) or coalescing-disabled-bufferable (x = 1, c = 0, b = 1) are vulnerable to this issue. in addition, regions configured as write through (x = 0, c = 1, b = 0) are also vulnerable to this issue. in addition, when caching is enabled in the mmu page tables, but the dcache is disabled in the cp15 arm control register, then the effective caching policy is bufferable and this reordering must be accounted for. it is important to realize that any code that accesses memory spaces on the internal bus must account for this possibility. code that dynam ically disables cache (for example, flash programming routines) must ensure that the caching policy for the appropriate memory region is set to ?stall until complete? until the cache is re-enabled. the simplest scenario to reproduce is a pair of back-to-back function calls, for example: main: bl fun1 bl fun2 ? ? ? fun1: stmfd sp!,{r4, r5, r6, r7, r8, r9, r10, lr} ldmfd sp!,{r4, r5, r6, r7, r8, r9, r10, pc} fun2: stmfd sp!,{r4, fp, ip, lr}
specification update 39 intel? 80333 i/o processor specification clarifications ldmfd sp!,{r4, fp, ip, pc} status: no fix . see the table , ?summary table of changes? on page 7 . 19. uart, i 2 c and gpio memory mapped registers should be addressed with 32-bit accesses issue: the uart, i 2 c and gpio units sit on a dedicated low-speed internal bus that does not support byte enables. due to this functionality, accessing an y of these unit memory-mapped registers (mmr) with any accesses less than 32-bits can result in co rruption of the other bits in the 32-bit mmr. for example, the gpod register (located at ffff_f788h) implements functionality for bit[10] and bit[11]. when software performs a byte access to gpod, this could cause bit[10] and bit[11] to be written with incorrect data. while most of these registers implement only the lower 8 bits (the upper three bytes are ?reserved?), the recommendation is that all uart, i 2 c, and gpio mmrs must be accessed only as 32-bit registers. while it is desired that 32-bit accesses be performed, it is acceptable to access with less than 32 bits, as long as all non-reserved bits are accessed. for purposes of future expansion, 32-bit accesses are preferred. status: no fix . see the table , ?summary table of changes? on page 7 . 20. uart interrupt identification register issue: the uart interrupt identification register (uxiir ) is read by software to determine the type and source of uart interrupts. this register gathers and priority encodes the various sources of uart interrupts. the register is read after an interrupt occurs. enabling and disabling of interrupts (via the interrupt enable register [uxier] or the modem control register [uxmcr]) affects whether or not the interrupt to the processor occurs. this do es not effect the logging of the status of what is happening in the uart. the uart operates in interrupt or polling mode. in polling mode, all interrupts to the processor are disabled. status: no fix . see the table , ?summary table of changes? on page 7 . 21. reads on 16-bit pbi bus operate as 32-bit issue: two-byte and four-byte read transactions on the peripheral bus interface (pbi) bus operate as burst reads (in other words, two 16-bit read cycles). all the read transactions from the intel xscale ? processor to pbi devices (such as sram, flash, and so on) are translated to burst reads with burst size of 2, even though there is no necessity to ge nerate a burst transaction. therefore, devices on the 16-bit pbi bus must be configured as pre-fetchable. note: single-byte transactions on 16-bit pbi bus is not a supported case. also, a pbi bus configured as 8-bit does not operate this way. status: no fix . see the table , ?summary table of changes? on page 7 . 22. 3.3 v to 1.5 v leakage issue: there is a leakage path from the 3.3 v rail to the 1.5 v rail. when the 3.3 v is powered-on and the 1.5 v is not, then ~500 mv is seen on the 1.5 v rail. this leakage is ex pected and does not cause any long-term reliability issues. for related issues, see non-core erratum 10 ( ?secondary bus pci rst# pulse prior to the rising edge of pwrgd? on page 17 ). status: no fix . see the table , ?summary table of changes? on page 7 .
40 specification update intel? 80333 i/o processor specification clarifications 23. accessing extended bridge configuration space from the intel xscale ? processor issue: in certain cases, the intel xscale ? processor might need to access the extended configuration space of the bridge headers (for ex ample, see non-core erratum 22 , ?incorrect default value for pci express* flow control protocol error severity bit? on page 21 ). when the intel xscale ? processor issues the configuration cycle addres s using occar, bits[27:24] can be used for addressing the extended space. for example, to access offset 10ch of a-bridge configuration space, use an address of 0x0101.000c for a type-zero configuration cycle. status: no fix . see the table , ?summary table of changes? on page 7 . 24. recommended b-segment termination when using the 80333 on pci express* adapter cards issue: for pci express* adapter cards, the b-segment is not used. assuming pciodten = 1 to enable internal pull-ups, the following external connections must be made for an unused b-segment: 1. connect b_clkout to b_clkin. the other clockouts can be turned off by software (pci clock control register at offset 43 in the b-segment bridge configuration space). 2. for b_pme#, use an 8.2 k ? pull-up. 3. for b_pcixcap, use a 3.3 k ? pull-up. 4. for b_rcomp, use 100 ? to ground. status: no fix . see the table , ?summary table of changes? on page 7 . 25. b-segment arbiter might not park on the last master when in pci-x 133 mhz mode issue: when the b-segment is running in pci-x 133 mhz mode, the arbiter might not park on the last master, when bit[8] of the internal arbiter co ntrol register (arb_cntrl[8], offset 16ah) is cleared. this happens only when the b-segment is ru nning at 133 mhz. when running at 66 mhz or 100 mhz, the arbiter parks the bus on the last master when arb_cntrl[8] is cleared. the a-segment does not exhibit this behavior with the same setup. status: no fix . see the table , ?summary table of changes? on page 7 . 26. configuring xintx# signals as pci interrupts issue: the pci specification rev. 2.3 states that pci interrupts are defined as ?level sensitive? and ?active low?. to configure the xintx# signals of the 80333 as ?level sensitive?, apic_rdlxx[15] (trigger mode) must be changed to 1 from its default of 0. to configure the xintx# signals of the 80333 as ?active low?, apic_rdlxx[13] (interrupt input pin polarity) must be changed to 1 from its default of 0. status: no fix . see the table , ?summary table of changes? on page 7 .
specification update 41 intel? 80333 i/o processor specification clarifications 27. power plane isolation for battery back-up (bbu) mode issue: during battery back-up (bbu) mode, when the battery powers the dimm and the vcc25/18 signals (1.8 v or 2.5 v, depending on the memory type being used) on a single power plane, the battery life will probably be reduced due to leakage. to attain longer battery life, the dimm and vcc25/18 power planes must be isolated. the power plane isolation can be accomplished by using a fet. status: no fix . see the table , ?summary table of changes? on page 7 . 28. aau result can be written directly to pci host memory issue: the application accelerator unit (aau) can write results not only to local me mory but also to the pci bus host memory via the atu. this feature can be applied to degraded raid-5 reads, where the aau result is the reconstructed data for the host i/o read. the aau can write its re sult to pci; therefore, the degraded read xor result can be written directly to host memory. this eliminates the need for a dma operation to transfer the result from local memory to host memory via pci. savings for the raid application include the following: ? no dma descriptor needs to be generated. ? no dma interrupt needs to be serviced. ? memory and internal bus bandwidth is saved (result write by aau and read by dma). ? read i/o is serviced faster (eliminates latency of dma operation). note: aau source reads from pci are not supported; only local memory can be used for this. status: no fix . see the table , ?summary table of changes? on page 7 . 29. smbus connection recommendations for pci express* adapter cards issue: pci express* cards based on the 80333 must implement the smbus signals in one of the following ways: 1. the smdat and smclk signals from the pci express* connector must be left as ?no connects?. the sclk and sdta signals on the 80 333 must have pull-ups even when they are not used. the pull-ups prevent the inputs from oscillating and potentially causing other problems. 2. when the smbus feature is required, an isolation device (for example, the ltc4301) must be placed between the smbus signals on the pci express* connector and the 80333, so that the system has no connection to the 80333 on these two signals when power is off. for motherboard designs, it is assumed that the smbu s is routed only to devices that are required and that remain powered. status: no fix . see the table , ?summary table of changes? on page 7 .
42 specification update intel? 80333 i/o processor specification clarifications 30. pbi lockout condition issue: when the core is in a tight loop writing to the pbi bus, while the dma is doing a large block transfer (for example, from sram, located on the pbi, to ddr memory), the dma can be locked out of accessing the pbi and the transaction will never complete. if this condition occurs, use one of these workarounds: 1. change the mttr1 from 98h (default) to a lowe r value (such as 01h). a lower value allows the dma (or atu which can also master a trans action to the pbi) to gain access to the pbi, because the biu is given shorter access for b ack-to-back biu internal bus transactions. 2. add a core read along with the core write, causing it stall and preventing it from starving the dma. 3. add nops or dummy instructions to ensure the loop spans greater than two cache lines. 4. modify the loop such that the write is not done on every iteration. status: no fix . see the table , ?summary table of changes? on page 7 . 31. pfreq functionality issue: the pfreq bits (bcnf[10:9], offset 40h) cannot be used to change the actual pci bus frequency. the only way to change the pci bus frequency is to reset the bus or use the hot-plug controller. note that this is an artifact of specification clarification 17 ( ?shpc sequence? on page 37 ). the same mechanism that requires two resets with the hot-plug controller, prevents the 33 mhz to/from 66 mhz pci transition without hot plug. other transi tions (such as pci-x) do work correctly; it is only the pci33 that cannot change to or from another bus speed. status: no fix . see the table , ?summary table of changes? on page 7 . 32. pwrdelay functionality during power sequencing issue: when the 3.3 v rail is powered on and the 1.5 v rail is powered off, the pwrdelay input signal drives out until the 1.5 v rail powers up. this is important to understand if still using the legacy power-fail circuit, because it might cause other circuitry to function incorrectly. the proper usage of pwrdelay is described in specification clarification 35 ( ?pwrdelay needs only a pull-up for battery back-up mode? on page 43 ), which recommends that pwrdelay be isolated from all circuitry and tied to a 1.5 k ? pull-up resistor. status: no fix . see the table , ?summary table of changes? on page 7 . 33. hpi# (high priority interrupt) is a maskable interrupt issue: the hpi# interrupt input is both maskable and masked by default (as are all interrupts). it is controlled by intctl1[31]. hpi# operates the same as the other external interrupt inputs (xint[7:0]#). status: no fix . see the table , ?summary table of changes? on page 7 . 34. ocd and receive enable calibration de-featured issue: the ability to adjust the electrical interface to account for out-of-specification ddr-ii dimms using ocd (off-chip driver) and receive enable ca libration, is no longer a supported feature. status: no fix . see the table , ?summary table of changes? on page 7 .
specification update 43 intel? 80333 i/o processor specification clarifications 35. pwrdelay needs only a pull-up for battery back-up mode issue: the i 2 c bus is no longer included in the processor reset equation. this allows the pwrdelay circuit to be simplified to a single pull-up resistor, to enable battery back-up mode. pwrdelay must be isolated from all other circuitry, and only a 1.5 k ? pull-up to 3.3 v is required. when battery back-up is not required, pwrdelay must have a 1.5 k ? pull-down resistor. status: no fix . see the table , ?summary table of changes? on page 7 . 36. pci express* l0s functionality not supported in the 80333 issue: due to the unreliable behavior described in non-core erratum 16 ( ?unreliable pci express* link operation when l0s active state power management is enabled? on page 19 ), l0s active power management state is not supported. the bios must be updated to leave l0s disabled on the 80333 by default, and eliminate any setup option with which to enable it. additionally, the bios must not allow l0s to be enabled on any pci express* r oot ports connected to the 80333 end-devices. status: no fix . see the table , ?summary table of changes? on page 7 . 37. ddrres2 can be pulled down to reduce current during self-refresh issue: ddrres2 is used as compensation for ddr-ii ocd. since ocd is not supported in the 80333 (see specification clarification 34 , ?ocd and receive enable calibration de-featured? on page 42 ), ddrres2 can be pulled down to reduce current draw during self-refresh mode. status: no fix . see the table , ?summary table of changes? on page 7 . 38. ddrslwcres resistor values issue: the following resistors can be used on ddrslwcres: ? ddr-i memory: 845 ? or 1.13 k ? resistor, 1% ? ddr-ii memory: 825 ? or 976 ? resistor, 1% status: no fix . see the table , ?summary table of changes? on page 7 . 39. b_pme# routing recommendation when using parallel hot plug 1-slot, no-glue mode issue: when the b-segment is in parallel hot plug, one-slot, no-glue mode, the b_pme# signal might be pulled to ground. since b_pme# is active low an d might be connected to the gipx pin of ichx, the ichx interprets the low voltage of b_pm e# as a power-management event from the pci-x slot. this might cause the system not to remain in the appropriate power mode when no add-in card is plugged into the slot. b_pme# must be high when there is no pme request from the pci-x slot. to work around this issue, add a diode between the buffer and the 80333, and add a 1 k ? ?10 k ? pull-up resistor to the b_pme# signal. the diod e can prevent ichx from getting a b_pme# low logic level when there is no pme request from the pci-x slot. status: no fix . see the table , ?summary table of changes? on page 7 .
44 specification update intel? 80333 i/o processor specification clarifications 40. multi-transaction timer grants fewer clocks in pci mode than expected issue: the multi-transaction timer (mtt, offset 42), in the bridge configuration header of the 80333, specifies the number of clocks that gnt# asserts to a master device on the pci bus. when running in pci-x mode, the number of clocks granted matches the value programmed in the mtt, but when in pci mode, the master is granted 16 clocks fewer than the value programmed in the mtt. the number of gnt# cycles is measured from the assertion of frame# to the deassertion of gnt# with req# asserted during the whole time. this behavior occurs on both the a- and b-bus segments and at both pci frequencies (33 mhz an d 66 mhz). for example, when the mtt value is 0x18, it produces 0x8 clocks between the assertion of frame# and deassertion of gnt#. another example: when the mtt value is 0x30, it produces 0x20 clocks between the assertion of frame# and deassertion of gnt#. status: no fix . see the table , ?summary table of changes? on page 7 . 41. byte enables (be) not included in pci delayed reads can cause data corruption issue: a pci device on one of the secondary busses th at generates a zero-length read request can cause data corruption in platforms utilizing non-intel? mch components, as the byte enables (be) are not included by the 80333 bridge in matching completions to pci delayed read requests. all intel? mch devices return data consistent with the ad dress of a zero-length read request. thus, no corruption can occur when a subseq uent non-zero-length read is inadvertently completed with data returned on behalf of the zero-length request, but this behavior is not required by specification. the following is an example case: 1. a memory read request with zero be is issu ed over pci; a corresponding zero-length read results on pci express* to the host. 2. a pci device on the same pci segment issues a mr/mrl/mrm to the same address with valid bes. 3. the 80333 bridge matches the completion for the memory read request on line 1 to the request on line 2 (in other words, bes are ignored). 4. unspecified data (returned for the zero-length read request) is driven to the pci card, resulting in data corruption. note: this affects pci mode exclusively, and is not an issue when the secondary busses are operating in pci-x mode. whether corruption can occur through this mechanism is dependent upon the behavior of the non-intel? mch component. if the mch in use behaves similarly to intel? mch designs, there is no exposure to data corruption, and the incomplete completion match does not have any side effects. status: no fix . see the table , ?summary table of changes? on page 7 . 42. interleaving aau descriptors issue: the p+q capability is enabled in the aau globally (acr.3), not on a descriptor by descriptor basis. therefore if enabled, all descriptors are pr ocessed as p+q descriptor formats. if disabled, all descriptors are processed as prior aau definitions (ie - straight xor). in order to mix raid-5 with p+q raid-6, enable p+q raid-6 gf multiply for the aau, and build all raid-5 xor descriptors as p+q raid-6 descriptors, where the gf multiplier byte values are all 0x01. status: no fix . see the table , ?summary table of changes? on page 7 .
specification update 45 intel? 80333 i/o processor specification clarifications 43. rcvdly setting for ddr-i memory issue: the receive enable delay register (rcvdly at ffff_f550h) is used for dqs receive enable calibration. in other words, rcvdly adjusts the memory controllers relationship of dqs to an internal m_clk. the rcvdly value is highly dependant on the bo ard layout and dimm characteristics. also, the memory controller only supports a non integer cas latency (tcas = 2.5, sdcr0.9:8) for ddr-i, which means that rcvdly may need to be adjust ed because dqs is no longer synchronized with m_clk. therefore, when using ddr-i memory the rcvdly default setting of 5, may need to be changed to 6 or 7 to operate correctly with a specific di mm based on the board layout. for example, the redboot reference code provided by intel uses a value to 7 in order to allow for a wider compatibility with various dimms. status: no fix . see the table , ?summary table of changes? on page 7 . 44. embedded usage models issue: the 80333 i/o processor was designed to be used as a pci-express endpoint. the pci-express interface on the 80333 does not have root complex support, therefore it cannot be used in an embedded application unless there is an upstr eam root complex that can control the 80333 pci-express port. also, data transfers between the a-segment pci bus and b-segment pci bus is not a supported configuration. these two pci busses are independent and only bridge to the pci-express interface. status: no fix . see the table , ?summary table of changes? on page 7 . 45. atubar3 functionality issue: the private memory window of the pci a-segment defines an address range that the 80333 uses to map private devices to, and to locate local memory for private device access. this range is intended to be mapped to the atus privat e bar window (atubar3) and the private device bars. note that even when the private addressing is enabled, the normal 80333 behavior defined for bme, mse, iose bits in the atucmd register are still true. therefore, when the atu memory space enable bit is cleared, all atu bars including atubar3 will be unable to claim any memory transactions. for example, this bi t is typically cleared during a pci bus scan / enumeration. status: no fix . see the table , ?summary table of changes? on page 7 . 46. vref isolation for battery back-up (bbu) mode issue: during battery back-up (bbu) mode, the dimm power can be isolated from the 80333 iop power. this isolation should also include the vref sign al for the dimm interface. due to leakage, the vref signal for the dimm should be isolated from the vref signal for the iop. this is to ensure that vref for the dimm is not disturbed as the iop powers down when entering battery back-up (bbu) mode. the isolation can be provided by using separate voltage dividers or a fet. for related issues, refer to specification clarification 27 , ?power plane isolation for battery back-up (bbu) mode? on page 41 . 47. i2c unit enabling issue: software must guarantee that the i2c bus is idle before enabling the i2c unit. failure to do so could result in unstable behavior. the ibmr register can be used to monitor the state of the scl and sda pins in order to determine bus activity. the i2c bus busy bit in the i2c status register (isr.3) can not be used for this purpose, as it is only valid when the i2c unit is enabled. status: no fix . see the table , ?summary table of changes? on page 7
46 specification update intel? 80333 i/o processor specification clarifications 48. dma transactions from local memory to a conventional pci target can complete out of order issue: it is possible for the outbound atu to get backed up and retry the dma unit. when this occurs, the possibility exists for dma transactions to complete out of order as each dma has 3 separate data queues and there is no guarantee as to which one of the queues will drain on the retry. status: no fix . see the table , ?summary table of changes? on page 7 49. sbr1 programming with bank 1 unpopulated issue: when using single-banked ddr-ii dimms and the sdram boundary register 1 (sbr1; ffff_e514h) is not programmed to match the sdram boundary register 0 (sbr0; ffff_e510h), the wrong odt signal will become activated. the memory controller provides two odt (on die termination) signals (odt[1:0]) which are used with ddr-ii dimms to turn on termination during writes. section 8.7.6 in the intel? 80333 i/o processor developer?s manual (305432) states, ?if bank 1 is unpopulated, sbr1[6:0] is programmed either with all zeroes or a value equal to sbr0[6:0].? to clarify this statement for single-banked ddr-ii di mms, if bank 1 is unpopulated, then the entire sbr1 must be programmed the same as sbr0. this includes lower bits 06:00 and upper bits 31:30. bits 30:07 are reserved and should not be written. the memory controller compares the entire range of the sbr0 and sbr1 to determin e which odt signal to enable. if the upper bits 31:30 in sbr0 and sbr1 do not match, then odt1 will become active instead of odt0. in addition, when bank 1 is unpopulated, sbr1[6:0] should never be zero if sbr0[6:0] is non-zero. status: no fix . see the table , ?summary table of changes? on page 7 50. 32-bit writes to unaligned 64-bit addresses are promoted to 64-bit aligned writes issue: in applications that run the pci bus segment in 32-bit pci mode or 64-bit pci mode with 32-bit targets, write transactions that are on unaligned 64-bit addresses are promoted to 64-bit aligned writes. the first half of the 64-bit write is on a 64-bit aligned address and has the be# signals disabled. therefore, the write is in valid. the second half on the 64-bit write is a valid write with the be# enabled and the write is to the intended 32-bit address. per the pci local bus specification, revision 2.2, pci compliant devices should ignore the first half of the 64-bit write due to the be# signals being disabled. for devices that support using the i/o window, the 64-bit write does not occur when using the atu i/o window and only the expected 32-bit write occurs. for memory mapped devices, the only option is to run in pci-x mode, where the byte count and starting address are consistent with the actual number of bytes to be written (i.e., 4). when a 64-bit pci-x request gets downshifted, the requester can use the starting address/byte count to recognize that the write request does not cross a dword address boundary and only perform a single 32-bit wide data cycle. status: no fix . see the table , ?summary table of changes? on page 7 51. atu retry response through the bridge issue: the bridge will not pass atu retry responses upstream through the bridge unless bit 15 in the pci express device control register (exp_dctl) re gister, located at offset 0x4c, is set to '1'. status: no fix . see the table , ?summary table of changes? on page 7
specification update 47 intel? 80333 i/o processor specification clarifications 52. case temperature clarification issue: internal models indicate that certain elevated case temperatures (tcase) of the intel? 80333 i/o processor may cause elevated field failures in la ter years of operation. this clarification is precautionary, as intel has not seen any failures of the 80333 products in the field. internal modeling data indicates that the degree of failure risk decreases with lower operating frequency (i.e. ? 500, 667, or 800mhz) and temperature (i.e. ? case temperature). if a failure should occur, it would manifest itself as a hard failure of the i/o processor which can cause a system failure. a detailed analysis of the system operating conditions, specifically case temperature of the 80333 i/o processor, is required. the 80333 should be r un with tcase temperatures that, over the lifetime of the part, average less than the 95 o c maximum tcase that is currently specified in the intel ? 80333 i/o processor datasheet (305433). tcase recommendations for the 80333: note: tcase temperatures in the table reflect an average tcase temperature over the lifetime of the product. status: fixed. this issue was fixed in the a-1 stepping of the product. see the table , ?summary table of changes? on page 7 . frequency 5 year operating life 6 year operating life 7 year operating life 500mhz 95 o c93 o c91 o c 667mhz 85 o c83 o c80 o c 800mhz 78 o c76 o c74 o c
48 specification update intel? 80333 i/o processor documentation changes documentation changes 1. pci clock timings table missing note issue: table 25 needs a note added referencing support of class 2 clock jitter. workaround: a fourth note has been adde d to table 25 and appears as follows: 4 - clock jitter class 2, per pci-x electrical and mechanical rev 2.0a specification affected docs: intel ? 80333 i/o processor datasheet (305433-001) 2. wrong voltage values in table 23 issue: table 23 shows wrong voltage values. workaround: replaced two rows in table 23. the two rows now appear as follows: affected docs: intel ? 80333 i/o processor datasheet (305433-002). 3. sbr1 programming when bank 1 is unpopulated issue: section 8.7.6 incorrectly states: ?if bank 1 is unpopulated, sbr1[6:0] is programmed either with all zeroes or a value equal to sbr0[6:0].? workaround: the sentence should be changed to ?if bank 1 is unpopulated, sbr1[6:0] and sbr1[31:30] should be programmed with a value equal to sbr0[6:0] and sbr0[31:30].? affected docs: intel? 80333 i/ o processor developer?s manual (305432-001) 4. pci express clock cycle time minimum issue: table 27 in the 80333 datasheet shows the pci express clock cycle time, tc2, as 10ns minimum. workaround: since the 80333 is compliant to pci-express 1.0a specification, this should be changed to 9.872ns minimum. affected docs: intel ? 80333 i/o processor datasheet (305433-003) v ol1 output low voltage (ddr sdram) 0.35 v i ol = 12.5 ma ( 1 , 2 ) v oh1 output high voltage (ddr sdram) 1.95 v i oh = -12.5 ma ( 1 , 2 )

▲Up To Search▲

Price & Availability of QG80333M500

	To Download QG80333M500 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .